Proteggere Controller di rete

Si applica a: Azure Stack HCI, versioni 23H2 e 22H2; Windows Server 2022, Windows Server 2019, Windows Server 2016

Questo articolo descrive come configurare la sicurezza per tutte le comunicazioni tra controller di rete e altri software e dispositivi.

I percorsi di comunicazione che è possibile proteggere includono la comunicazione Northbound nel piano di gestione, la comunicazione del cluster tra macchine virtuali del controller di rete (VM) in un cluster e la comunicazione southbound nel piano dati.

1. Comunicazione northbound. Il controller di rete comunica sul piano di gestione con software di gestione che supporta SDN, ad esempio Windows PowerShell e System Center Virtual Machine Manager (SCVMM). Questi strumenti di gestione offrono la possibilità di definire i criteri di rete e di creare uno stato obiettivo per la rete, in base al quale è possibile confrontare la configurazione di rete effettiva per portare la configurazione effettiva in parità con lo stato dell'obiettivo.

2. Comunicazione del cluster del controller di rete. Quando si configurano tre o più macchine virtuali come nodi del cluster controller di rete, questi nodi comunicano tra loro. Questa comunicazione può essere correlata alla sincronizzazione e alla replica dei dati tra nodi o a una comunicazione specifica tra i servizi del controller di rete.

3. Comunicazione a sud. Il controller di rete comunica sul piano dati con l'infrastruttura SDN e altri dispositivi, ad esempio servizi di bilanciamento del carico software, gateway e computer host. È possibile usare Il controller di rete per configurare e gestire questi dispositivi a sud in modo che mantengano lo stato di obiettivo configurato per la rete.

Comunicazione northbound

Il controller di rete supporta l'autenticazione, l'autorizzazione e la crittografia per la comunicazione northbound. Le sezioni seguenti forniscono informazioni su come configurare queste impostazioni di sicurezza.

Authentication

Quando si configura l'autenticazione per la comunicazione northbound del controller di rete, è possibile consentire ai nodi del cluster del controller di rete e ai client di gestione di verificare l'identità del dispositivo con cui comunicano.

Il controller di rete supporta le tre modalità di autenticazione seguenti tra i client di gestione e i nodi del controller di rete.

Nota

Se si distribuisce controller di rete con System Center Virtual Machine Manager, è supportata solo la modalità Kerberos.

1. Kerberos. Usare l'autenticazione Kerberos quando si uniscono sia il client di gestione che tutti i nodi del cluster controller di rete a un dominio di Active Directory. Il dominio di Active Directory deve avere account di dominio usati per l'autenticazione.

2. X509. Usare X509 per l'autenticazione basata su certificati per i client di gestione non aggiunti a un dominio di Active Directory. È necessario registrare i certificati in tutti i nodi del cluster e i client di gestione del controller di rete. Inoltre, tutti i nodi e i client di gestione devono considerare attendibili i certificati degli altri.

3. Nessuno. Usare Nessuno a scopo di test in un ambiente di test e pertanto non è consigliabile usarlo in un ambiente di produzione. Quando si sceglie questa modalità, non viene eseguita alcuna autenticazione tra nodi e client di gestione.

È possibile configurare la modalità di autenticazione per la comunicazione Northbound usando il comando Windows PowerShell Install-NetworkController con il parametro ClientAuthentication.

Autorizzazione

Quando si configura l'autorizzazione per la comunicazione northbound del controller di rete, è possibile consentire ai nodi del cluster controller di rete e ai client di gestione di verificare che il dispositivo con cui comunica sia attendibile e abbia l'autorizzazione per partecipare alla comunicazione.

Usare i metodi di autorizzazione seguenti per ognuna delle modalità di autenticazione supportate dal controller di rete.

1. Kerberos. Quando si usa il metodo di autenticazione Kerberos, si definiscono gli utenti e i computer autorizzati a comunicare con il controller di rete creando un gruppo di sicurezza in Active Directory e quindi aggiungendo utenti e computer autorizzati al gruppo. È possibile configurare Controller di rete per l'uso del gruppo di sicurezza per l'autorizzazione usando il parametro ClientSecurityGroup del comando Install-NetworkController Windows PowerShell. Dopo aver installato il controller di rete, è possibile modificare il gruppo di sicurezza usando il comando Set-NetworkController con il parametro -ClientSecurityGroup. Se si usa SCVMM, è necessario specificare il gruppo di sicurezza come parametro durante la distribuzione.

2. X509. Quando si usa il metodo di autenticazione X509, Il controller di rete accetta solo le richieste dai client di gestione le cui identificazioni personali del certificato sono note al controller di rete. È possibile configurare queste identificazioni personali usando il parametro ClientCertificateThumbprint del comando Install-NetworkController Windows PowerShell. È possibile aggiungere altre identificazioni personali del client in qualsiasi momento usando il comando Set-NetworkController .

3. Nessuno. Quando si sceglie questa modalità, non viene eseguita alcuna autenticazione tra nodi e client di gestione. Usare Nessuno a scopo di test in un ambiente di test e pertanto non è consigliabile usarlo in un ambiente di produzione.

Crittografia

La comunicazione in ingresso settentrionale usa Secure Sockets Layer (SSL) per creare un canale crittografato tra i client di gestione e i nodi del controller di rete. La crittografia SSL per la comunicazione Northbound include i requisiti seguenti:

• Tutti i nodi del controller di rete devono avere un certificato identico che include l'autenticazione server e l'autenticazione client nelle estensioni EKU (Enhanced Key Usage).

• L'URI usato dai client di gestione per comunicare con il controller di rete deve essere il nome soggetto del certificato. Il nome soggetto del certificato deve contenere il nome di dominio completo (FQDN) o l'indirizzo IP dell'endpoint REST del controller di rete.

• Se i nodi del controller di rete si trovano in subnet diverse, il nome del soggetto dei certificati deve corrispondere al valore usato per il parametro RestName nel comando install-NetworkController Windows PowerShell.

• Tutti i client di gestione devono considerare attendibile il certificato SSL.

Registrazione e configurazione dei certificati SSL

È necessario registrare manualmente il certificato SSL nei nodi del controller di rete.

Dopo aver registrato il certificato, è possibile configurare Controller di rete per l'uso del certificato con il parametro -ServerCertificate del comando Install-NetworkController Windows PowerShell. Se il controller di rete è già installato, è possibile aggiornare la configurazione in qualsiasi momento usando il comando Set-NetworkController .

Nota

Se si usa SCVMM, è necessario aggiungere il certificato come risorsa di libreria. Per altre informazioni, vedere Configurare un controller di rete SDN nell'infrastruttura di VMM.

Comunicazione del cluster del controller di rete

Il controller di rete supporta l'autenticazione, l'autorizzazione e la crittografia per la comunicazione tra i nodi del controller di rete. La comunicazione avviene tramite Windows Communication Foundation (WCF) e TCP.

È possibile configurare questa modalità con il parametro ClusterAuthentication del comando Install-NetworkControllerCluster Windows PowerShell.

Per altre informazioni, vedere Install-NetworkControllerCluster.

Authentication

Quando si configura l'autenticazione per la comunicazione del cluster di controller di rete, è possibile consentire ai nodi del cluster controller di rete di verificare l'identità degli altri nodi con cui comunicano.

Il controller di rete supporta le tre modalità di autenticazione seguenti tra i nodi del controller di rete.

Nota

Se si distribuisce Controller di rete tramite SCVMM, è supportata solo la modalità Kerberos .

1. Kerberos. È possibile usare l'autenticazione Kerberos quando tutti i nodi del cluster controller di rete vengono aggiunti a un dominio di Active Directory, con account di dominio usati per l'autenticazione.

2. X509. X509 è l'autenticazione basata su certificati. È possibile usare l'autenticazione X509 quando i nodi del cluster controller di rete non vengono aggiunti a un dominio di Active Directory. Per usare X509, è necessario registrare i certificati in tutti i nodi del cluster controller di rete e tutti i nodi devono considerare attendibili i certificati. Inoltre, il nome soggetto del certificato registrato in ogni nodo deve corrispondere al nome DNS del nodo.

3. Nessuno. Quando si sceglie questa modalità, non viene eseguita alcuna autenticazione tra i nodi del controller di rete. Questa modalità viene fornita solo a scopo di test e non è consigliata per l'uso in un ambiente di produzione.

Autorizzazione

Quando si configura l'autorizzazione per la comunicazione del cluster del controller di rete, è possibile consentire ai nodi del cluster controller di rete di verificare che i nodi con cui comunicano siano attendibili e abbiano l'autorizzazione per partecipare alla comunicazione.

Per ognuna delle modalità di autenticazione supportate dal controller di rete, vengono usati i metodi di autorizzazione seguenti.

1. Kerberos. I nodi del controller di rete accettano le richieste di comunicazione solo da altri account computer controller di rete. È possibile configurare questi account quando si distribuisce Controller di rete usando il parametro Name del comando New-NetworkControllerNodeObject Windows PowerShell.

2. X509. I nodi del controller di rete accettano le richieste di comunicazione solo da altri account computer controller di rete. È possibile configurare questi account quando si distribuisce Controller di rete usando il parametro Name del comando New-NetworkControllerNodeObject Windows PowerShell.

3. Nessuno. Quando si sceglie questa modalità, non viene eseguita alcuna autorizzazione tra i nodi del controller di rete. Questa modalità viene fornita solo a scopo di test e non è consigliata per l'uso in un ambiente di produzione.

Crittografia

La comunicazione tra nodi del controller di rete viene crittografata usando la crittografia a livello di trasporto WCF. Questa forma di crittografia viene usata quando i metodi di autenticazione e autorizzazione sono certificati Kerberos o X509. Per ulteriori informazioni, vedere gli argomenti seguenti.

• Procedura: Proteggere un servizio con credenziali di Windows
• Procedura: Proteggere un servizio con certificati X.509.

Comunicazione a sud

Il controller di rete interagisce con diversi tipi di dispositivi per la comunicazione southbound. Queste interazioni usano protocolli diversi. Per questo motivo, esistono requisiti diversi per l'autenticazione, l'autorizzazione e la crittografia a seconda del tipo di dispositivo e del protocollo usato dal controller di rete per comunicare con il dispositivo.

Nella tabella seguente vengono fornite informazioni sull'interazione del controller di rete con diversi dispositivi a sud.

Dispositivo/servizio a sud	Protocollo	Autenticazione usata
Bilanciamento del carico software	WCF (MUX), TCP (host)	Certificati
Firewall	OVSDB	Certificati
Gateway	WinRM	Kerberos, certificati
Reti virtuali	OVSDB, WCF	Certificati
Routing definito dall'utente	OVSDB	Certificati

Per ognuno di questi protocolli, il meccanismo di comunicazione è descritto nella sezione seguente.

Authentication

Per la comunicazione southbound, vengono usati i protocolli e i metodi di autenticazione seguenti.

1. WCF/TCP/OVSDB. Per questi protocolli, l'autenticazione viene eseguita usando certificati X509. Sia il controller di rete che i computer host (SLB) Multiplexer (SLB) peer presentano i certificati tra loro per l'autenticazione reciproca. Ogni certificato deve essere considerato attendibile dal peer remoto.

   Per l'autenticazione southbound, è possibile usare lo stesso certificato SSL configurato per crittografare la comunicazione con i client Northbound. È anche necessario configurare un certificato nei dispositivi MUX E HOST SLB. Il nome soggetto del certificato deve essere uguale al nome DNS del dispositivo.

2. WinRM. Per questo protocollo, l'autenticazione viene eseguita tramite Kerberos (per i computer aggiunti a un dominio) e usando i certificati (per computer non aggiunti a un dominio).

Autorizzazione

Per la comunicazione southbound, vengono usati i protocolli e i metodi di autorizzazione seguenti.

1. WCF/TCP. Per questi protocolli, l'autorizzazione è basata sul nome soggetto dell'entità peer. Controller di rete archivia il nome DNS del dispositivo peer e lo usa per l'autorizzazione. Questo nome DNS deve corrispondere al nome soggetto del dispositivo nel certificato. Analogamente, il certificato del controller di rete deve corrispondere al nome DNS del controller di rete archiviato nel dispositivo peer.

2. WinRM. Se si usa Kerberos, l'account client WinRM deve essere presente in un gruppo predefinito in Active Directory o nel gruppo Administrators locale nel server. Se vengono usati certificati, il client presenta un certificato al server che il server autorizza usando il nome soggetto o l'autorità di certificazione e il server usa un account utente mappato per eseguire l'autenticazione.

3. OVSDB. L'autorizzazione è basata sul nome soggetto dell'entità peer. Controller di rete archivia il nome DNS del dispositivo peer e lo usa per l'autorizzazione. Questo nome DNS deve corrispondere al nome soggetto del dispositivo nel certificato.

Crittografia

Per la comunicazione southbound, per i protocolli vengono usati i metodi di crittografia seguenti.

1. WCF/TCP/OVSDB. Per questi protocolli, la crittografia viene eseguita usando il certificato registrato nel client o nel server.

2. WinRM. Il traffico WinRM viene crittografato per impostazione predefinita usando il provider di supporto per la sicurezza Kerberos. È possibile configurare Crittografia aggiuntiva, sotto forma di SSL, nel server WinRM.